[レポート] DAT304: ディープ・ダイブ・オン MySQL互換Amazon Aurora #reinvent

AWS re:Invent 2018

#Amazon RDS

#Auroraマルチマスタークラスター

#Aurora Serverless

#Amazon Aurora

#AWS

Guri / Hajime Oguri

2018.12.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大栗です。

re:InventでMySQL互換Auroraのディープダイブセッションに参加したのでレポートします。

レポート

Amazon Auroraはオープンソース料金のエンタープライズデータベースであり、マネージドサービスとして提供している

Auroraはたくさん顧客が導入しており、AWS史上最も早く成長している。

パフォーマンス

伝統的なデータベースアーキテクチャ

一つの箱にモノリシックなスタックでコンピュートとストレージが結合している

伝統的な分散データベーススタック

シャーディング
シェアード・ナッシング
シェアード・ディスク

同じモノリシックなスタックで、分散合意アルゴリズムが貧弱である。

Aurora: スケールアウトな分散アーキテクチャ

アプリケーションからストレージへログをプッシュする

4/6書き込みクォーラムとローカルトラッキング

ログアプリケータの動作

マスタへ順々に書き込まれたデータがストレージのページに対して順々に書き込まれ、レプリカへ非同期でレプリケーションされる。オンデマンドでログが提供されて、レプリカもそのログを読み込んでいく。つまりログがデータベース！

MySQL vs Aurora I/Oプロファイル

MySQLとレプリカではマスタがストレージに書き込むデータと同じものをレプリカインスタンスに送る必要がある。

Amazon Auroraでは非同期な4/6クォーラムでストレージに書き込み、一分のデータのみレプリカに送る。

Sysbenchの計測でトランザクション数が35倍増え、トランザクションあたりのI/O回数が7.7倍減る。

読み書きスループット

Aurora MySQLはMySQLと比べて5倍高速

バルクデータロードのパフォーマンス

Aurora MySQLはMySQLと比べて2.5倍高速

読み込みスケールアウト

MySQLでは、論理的に変更したデータ全体を書き込み、マスタへの書き込みと同量の書き込みをレプリカにも行う必要がある。

Amazon Auroraでは、物理的に変更した差分を書き込み、レプリカに書き込まない

Aurora MySQLの論理と物理のレプリカラグ

Auroraの論理レプリカラグは増えていくが、Auroraの物理レプリカラグは20ms程度で安定する。

クォーラムとローカルトラッキングの動作

待っているトランザクションが4個あるとする。各々がストレージに書き込まれコミットするが、一部のトランザクションデータで書き込みが6個全部完了していない状態になったとする。書き込みが完了していないストレージノードは内部でレプリケーションされるので、重い分散コミットは不要。

負荷時の性能変化

レスポンスタイムが、Amazon Auroraは安定するがMySQLでは安定しない

スレッドモデルが、MySQLではクライアントの接続ごとに独立しているが、Auroraではepoll()で受けてラッチ無しのタスクキューに入れられる。

そのためMySQLのロックマネージャではスキャンを行うと各処理がロックされるが、Auroraではスキャンと並行して削除や挿入を行える。

時間経過での性能向上

2015年から2018年で、最大書き込みスループットや最大読み込みスループットが伸びている。

パフォーマンスパラメータは何か？

異なるハードウェア設定に対する事前チューニングか自動チューニング

リカバリ時間 vs 書き込み性能

MySQLではチェックポイントの大きさによって書き込み性能とともにリカバリ時間も伸びるがAuroraは書き込み性能が高くてもリカバリ時間が短い。もはやリカバリ時間と書き込み性能はトレードオフではない！

分散データベースの比較

既存のマルチマスタソリューション

分散ロックマネージャ

非常に重い同期処理で悲観的でネガティブなスケーリング

読み書きできるグローバルな順序付け

グローバルエンティティ：スケーリングがボトルネック

2層コミットのPaxosリーダー

非常に重い合意プロトコル：パーティション超えクエリによるホットパーティションと奪い合い

Auroraマルチマスタのアーキテクチャ

悲観的ロック無し
グローバルな順序付け無し
グローバルなコミット調整無し
楽観的コンフリクト解決
分離されたシステム
マイクロサービスアーキテクチャ

Auroraマルチマスタの動作（幸運なパス）

異なるマスタが異なるテーブルに対してコンフリクトがない書き込みを行う。この場合は同期不要。

Auroraマルチマスタの動作（物理的なコンフリクト）

異なるマスタが同じテーブルに対して物理的なコンフリクトがある書き込みを行う。この場合は楽観的コンフリクト解決を行う。

Auroraマルチマスタの動作（論理的なコンフリクト）

異なるマスタが同じテーブルに対して論理的なコンフリクトがある書き込みを行う。この場合は分散ロックが不要。

Auroraマルチマスタのグローバルリードとは？

（筆者注：マスチマスタの動作について理解が不足しているので、セッション動画を見ることをお勧めします）

Auroraマルチマスタ間は非同期でデータをやり取りしている。各々はSingleというステータスになっている。あるマスタノードに対して更新すると対象マスタがEngagedのステータスとなる。別のマスタに対してローカルリードする場合は、個別のノードのデータを読み込み、グローバルリードを行う時には別の元データにアクセスしてステータスがEngagedになります。